Portable and architecture independent parallel performance tuning using a call-graph profiling tool

This paper describes a post-mortem call-graph profiling tool that analyses trace information generated during the execution of BSPlib programs. The purpose of the tool is to expose imbalance in either computation or communication, and to highlight portions of code that are amenable to improvement. Unlike other profiling tools, the profile information guides optim-isation in an architecture independent way. From an ease of use perspective, the amount of information displayed when visualising a profile f o r a parallel program is no more complex than that of a sequential program. 1 Introduction The role of a profiling tool is to associate computational bottlenecks that arise during program execution with easily identifiable segments of the source code. The usefulness of a profiling tool depends upon the ease in which users can employ this information to alleviate identified bottlenecks within their programs. The success of profiling tools in sequential languages has been predominantly based on the employment of three criteria as the platform on which profiling tools are built. The first of these criteria is 'what' is measured; typically this might be the percentage of execution time spent in each part of the program. The second criteria is 'where' in the code these costs should be attributed; costs may be associated with functions or libraries for example. The third criteria is 'how-to-use' the profiling information to optimise programs in a quantifiable and portable way; for example, problematic portions of code may be rewritten using an algorithm with improved asymptotic complexity. The difference between profiling parallel programs as opposed to sequential programs is that parallel programs are executed on a number of processors. Consequently , each part of the code may be associated with up-to p costs, where p is the number of processors. The major challenge for the developers of profiling tools for parallel languages is to identify and expose the relationship (imbalance) of computational costs amongst processors, and subsequently express this relationship in terms of the three criteria outlined above. Unfortunately, within a parallel framework, there is a multiplicity of interacting issues that make these criteria significantly more obscure and complex: What-to-cost In parallel programming there are at least two kinds of cost which can cause bottlenecks within programs, computation and communication. These costs should not be decoupled and profiled independently as it is of paramount importance that the interaction between the two is identified and exposed to the user. The motivation …